专利摘要:
通信ネットワークにおいて第1のノード(102)と第2のノード(101)との間に暗号化関係を確立するための方法および装置である。第1のノードは、第2のノードの暗号化属性の少なくとも一部を受信し、そして、受信した暗号化属性の少なくとも一部を用いて第1のノード用の識別子を生成する。暗号化属性は、第2のノードに属する公開鍵であってもよく、そして、識別子は、暗号化によって生成されたIPアドレスであってもよい。暗号化関係によって、第2のノードが、第1のノードに代わって動作する権限を有する第3のノードと確立することが可能になる。 なし
公开号:JP2011505729A
申请号:JP2010534488
申请日:2008-11-21
公开日:2011-02-24
发明作者:マッツ ネスルンド,;ワシム ハダッド,
申请人:テレフオンアクチーボラゲット エル エム エリクソン(パブル);
IPC主号:H04W12-02
专利说明:

[0001] 本発明は、通信ネットワークの分野に関し、詳細には、通信ネットワーク内の2つのノード間に暗号化関係を確立することに関するものである。]
背景技術

[0002] 2004年6月のRFC3775、D.Johnson、C.Perkins、およびJ.Arkko著「IPv6におけるモビリティサポート(Mobility Support in IPv6)」の中で記載されているモバイルIPv6(MIPv6)は、移動通信デバイスのユーザが、どのネットワーク内にいるかに関らず、恒久的なIPアドレスを維持しながら1つのネットワークから別のネットワークへ移動することを可能にする。これによって、ユーザは、移動中も接続を維持することができる。例えば、あるユーザがボイスオーバIP(Voice Over IP)(VoIP)セッションに参加していて、セッションの間にそのユーザが1つのネットワークから別のネットワークへ移動した場合には、MIPv6サポートがなければユーザのIPアドレスは変わる可能性がある。これでは、VoIPセッションでいくつかの問題が生じるであろう。]
[0003] 移動ノード(Mobile Node:MN)には、恒久的なホームアドレスと気付アドレス(CoA)という2つのIPアドレスが割り当てられる。CoAは、ユーザが現時点で訪問しているアクセスネットワークであるIPサブネットに関連付けられている。MNと通信するために、パケットは、MNのホームアドレスへ送信される。これらのパケットは、MNのホームネットワーク内のホームエージェント(Home Agent:HA)によって捕捉される。HAは現在のCoAの知識を持っている。次いで、ホームエージェントは、元のIPヘッダを維持しながら、新たなIPヘッダを使ってパケットをMNのCoAへトンネルする。MNによってパケットが受信されると、新たなIPヘッダを削除して元のIPヘッダを取得する。MNは、HAへとアドレス指定されたパケットの中にカプセル化されたかたちでパケットをHAへトンネルすることによって、パケットを別のノードへ送信する。各パケットについて、HAは、カプセル化パケットを削除して元のパケットを復元し、そしてそれを意図する宛先ノードへ転送する。]
[0004] プロキシモバイルIPv6(Proxy Mobile IPv6)(PMIPv6)、IETF draft−sgundave−mip6−proxymip6−07は、モバイルアクセスゲートウェイ(Mobile Access Gateway)(MAG)機能について記載している。この機能は、MNが自身のホームネットワーク上にいるかのようにMNに振舞わせることを目的としてホームリンクプロパティをエミュレートし、普通ならMIPv6をサポートしないはずのネットワーク上での移動性をサポートすることを可能にする。PMIPv6とMIPv6との主な違いは、MIPv6を使用すると、MNは自分自身の移動性シグナリングの制御権を有しているのに対し、PIMPv6を使用すると、MNは、自身の移動性シグナリングの制御権を有さないという点である。PMIPv6アーキテクチャの基本的な構成要素が図1に示される。] 図1
[0005] MAG101は、通常、アクセスルータに実装される。MAG101は、移動性関連のシグナリングをMN102に代わって送受信する。MN102がMAG101を有するアクセスルータに接続する場合、アクセス認証手順の一部として自身のアイデンティティをネットワークアクセス識別子(Network Access Identifier)(NAI)の形式で提示する。MN102が一旦認証されると、MAGは、ポリシー記憶装置からユーザプロファイルを取得する。MAG101は、ユーザプロファイルとNAIの知識を有しているで、今度はMNのホームネットワークをエミュレートすることができる。MN102は、その後、自身のホームアドレスをMAGから取得する。また、MAG101は、プロキシバインディング更新(Proxy Binding Update)メッセージを使用してMN102の現在位置をMN102のローカルモビリティアンカー(Local Mobility Anchor)(LMA)103に通知する。プロキシバインディング更新(Proxy Binding Update)メッセージは、MN102のNAIを使用する。プロキシバインディング更新(Proxy Binding Update)メッセージを受信すると、LMA103は、MAG101へのトンネルをセットアップし、プロキシバインディング確認応答(Proxy Binding Acknowledgement)メッセージをMAGへ送信する。ロキシバインディング確認応答(Proxy Binding Acknowledgement)メッセージを受信すると、MAG101は、事実上双方向トンネルを形成するかたちで、LMAへのトンネルをセットアップする。MN102で発着信するすべてのトラフィックは、双方向トンネルを介してLMA103を通ってルーティングされる。1つのMAGは、同一のLMAに関連付けられている多数のMNにサービスを提供することができる。MAGおよびLMAは、各MNについて専用の双方向トンネルを有する必要がない。その代わり、同一のLMAに関連付けられ、かつ、同一のMAGによって現時点でサービスが提供されているすべてのMNのトラフィックについて、同一の双方向トンネルを使用することができる。]
[0006] LMA103は、MN102へ送信されるパケットをいずれも捕捉して、その捕捉されたパケットをトンネルを通してMAG101へ転送する。パケットを受信すると、MAG101は、トンネルヘッダを削除して、パケットをMN102へ送信する。MAG101は、アクセスリンク上のデフォルトルータとして動作する。MNから送信されるパケットはいずれも、MAG101を介してトンネルを通ってLMA103へ送信され、次いで、LMA103は、パケットをその最終的な宛先へと送信する。]
[0007] 2007年5月のIETF、RFC4866、J.Arkko、C.Vogt、およびW.Haddad著「モバイルIPv6用の拡張ルート最適化(Enhanced Route Optimization for Mobile IPv6)」の中で記載されている拡張ルート最適化(Enhanced Route Optimization)(ERO)は、MIPv6ルート最適化に対する修正を規定している。EROは、暗号化によって、かつ、検証可能な形でMNの公開鍵/秘密鍵ペアの公開成分にバインディングされたインタフェース識別子を使用することによって、MNのホームアドレスのなりすましに対してセキュアにする。EROによって、移動ノードと対向ノードとが、気付アドレステストを実行することによって双方向通信を並行して再開できるようになる。暗号化によって生成されたアドレス(Cryptographically Generated Address:CGA)をMNのために使用することは、セキュリティの向上とシグナリングオーバヘッドの削減とにつながる。CGAは、2005年3月のIETF、RFC3972、T.Aura著「暗号化生成アドレス(Cryptographically Generated Address)(CGA)」の中で記載されている。]
[0008] しかしながら、PMIPv6に従えば、MNは「移動性に気付かない」状態であるべきであることから、EROをPMIPv6対応ネットワークに適用することはできない。MNに代わってEROをPMIPv6対応ネットワークに適用することは、MNが自身のCGA秘密鍵を訪問先ネットワーク内に位置する各ノード(例えば、MAG)と共有することが必要となるであろう。これはセキュリティの観点から、明らかに望ましくない。また、MNが、自身の秘密鍵を共有する必要があるという事実は、MNが移動性に完全に気付かないわけにはいかないということを意味する。]
[0009] CGA技術は、現在、MAG、HA、LMA、CNを含む、PMIPv6対応ネットワークで使用されていて、多数の冗長な移動性シグナリングメッセージを削減しており、従って、CGA技術を使用するPMIPv6用のルート最適化メカニズムがあれば、有利であろう。]
[0010] 従って、CGA技術を使用し、かつ訪問先ネットワーク内でMNのために使用することが可能であるけれどもMNが自身の秘密鍵を訪問先ネットワーク内の他の各ノードと共有することを要求しないようなルート最適化メカニズムを考案することは、望ましいことであろう。さらに、セキュア近隣ディスカバリ(Secure Neighbor Discovery)(SeND)状況において、PMIPv6ネットワーク内でMNがSeNDメッセージを送信することを、例えば、Access Routerのようなプロキシノードに委任できるようにすることは、有益であろう。SeNDメッセージに関する研究については、2007年2月12日−14日の第9回高度通信技術における国際会議でのPark他による「セキュア近隣ディスカバリとマルチキー暗号化生成アドレスの外観(A Survey of the Secure Neighbor Discovery(SeND)and Multi−Key Cryptographically Generated Addresses)(MSGAs)」、Vol.3、2124−2127ページで調査されている。]
[0011] MNが一定のタスクをセキュアな方法でプロキシノードに委任することができることは、例えば、演算負荷/処理負荷からMNを解放することは、望ましいであろう。ここでセキュアな方法とは、プロキシノードがMNに代わって動作を実行することを認可されていて、かつ、プロキシノードがそれを行うことに同意していることを第三者が検証することが可能であるべきだということを意味する。]
発明が解決しようとする課題

[0012] これを行う1つの方法は、プロキシノードとMNとが相互に、例えば、相手の公開鍵に署名することによって、「相互認証する」ことであろう。しかしながら、これには2つの大きな欠点がある。第1に、そのような手法の一般性に起因して、MNがそれによってどのタイプのタスクを委任することに合意するのかが若干不明確であることである。逆に言えば、プロキシノードがMNに代わって何をすることに合意したのかが若干不明確であることである。第2に、電子署名を実行することが必要であるため、MNに演算負荷を課すことになる。]
[0013] 本発明者らは、第1のノードについての暗号化生成アドレス(Cryptographically Generated Address)を生成するための新たな手法を考案している、これによって、第1のノードは、第2のノードと暗号化関係を確立することができる。これによって、第2のノードは、自身が第1のノードと関係を有することを別の各ノードに証明することができる。第1のノードがプロキシモバイルIP(Proxy Mobile IP)ネットワーク内の移動ノードであり、第2のノードがその移動ノードにサービスを提供しているホームエージェント(Home Agent)である場合、秘密の暗号化材料を訪問先ネットワーク内の他のノードと共有することをMNに要求することなく、MNとHAとの間の暗号化関係が、HAがMNのためのルート最適化を提供する目的で使用される。第1のノードが移動ノードであり、第2のノードがアクセスルータ(Access Router)である場合、暗号化関係によって、MNは、セキュア近隣ディスカバリ(SeND)プロトコルの責任をアクセスルータに委任することができ、それは、ARが、自身がMNと暗号化関係を有することを他の各ノードに示すことができるからである。]
課題を解決するための手段

[0014] 本発明の第1の態様に従えば、通信ネットワークにおいて第1のノードと第2のノードとの間で暗号化関係を確立する方法を提供する。この方法は、第1のノードにおいて、第2のノードから、その第2のノードに属する暗号化属性の少なくとも一部を受信することを含んでいる。次いで、第1のノードは、第1のノードの識別子を生成するために、受信した暗号化属性の少なくとも一部と、第1のノードに属する暗号化属性の少なくとも一部とを使用する。第1のノードの識別子を生成するために第2のノードの暗号化属性を使用することは、必要に応じて第三者に実証することのできる、2つのノード間の信頼関係を確立する。識別子が第1のノードでの一定の方法で生成されるという事実は、第1のノードが第2のノードとの信頼関係を喜んで築いていることを実証する目的で使用することが可能であり、そして、第2のノードが、第1のノードの同意なく第1のノードとの信頼関係を実証しようとすることを阻止する。]
[0015] オプションで、第1のノードの識別子は、暗号化によって生成されたIPアドレス(Cryptographically Generated IP address)を含み、そして、この暗号化属性は、第2のノードに属する公開鍵であってもよい。また、この方法は、オプションで、第1のノードにおいて、第2のノードに属する暗号化属性をランダム値と連結することと、連結された結果をハッシュすることと、そして、第1のノードにおいて、結果として得られたハッシュ値の少なくとも一部を識別子を生成するための修飾子として使用することとを含んでいる。この場合、この方法は、オプションで、第2のノードにおいて、第1のノードの識別子とランダム値とを第3のノードへ送信することと、そして、第3のノードにおいて、第2のノードが第1のノードと信頼関係を有することを検証するために、第1のノードに属する識別子とランダム値とを使用することとを含んでいる。「ランダム値」という用語は、本明細書では、ランダムにまたは擬似ランダムに生成されている値を示すために使用される。オプションとして、この方法は、さらに、第2のノードにおいて、第1のノードに属する識別子とランダム値とを含むメッセージに署名することを含んでもよい。]
[0016] 通信ネットワークは、オプションで、プロキシモバイルIPネットワークを含み、ここで、第1のノードは移動ノードであり、第2のノードはその移動ノードに関連付けられているホームエージェントである。これによって、ホームエージェントは、移動ノードに代わってルート最適化を提供することができる。]
[0017] オプションで、第1のノードは移動ノードであり、第2のノードは、それを介して移動ノードが通信ネットワークに接続するプロキシノードである。これは、例えば、それぞれ移動ノードと移動アクセスゲートウェイ(Mobile Access Gateway)とであってもよい。オプションで、プロキシノードは、移動ノードに代わってセキュア近隣ディスカバリ(Secure Neighbor Discovery)メッセージを送信する。]
[0018] この方法は、オプションで、さらに、第2のノードにおいて、第1のノードに関するフラッディング攻撃を検出することを含んでいる。その検出の結果として、第2のノードは、フラッシュリクエストメッセージを第3のノードへ送信する。このフラッシュリクエストメッセージは、第1のノードに関するすべてのバインディングキャッシュエントリ(Binding Cache Entries)をフラッシュすることを第3のノードに命令するものである。フラッシュリクエストメッセージは、第1のノードに属する識別子と、識別子を生成するために使用されるその他の暗号化材料とを含んでいる。このようにして、第1のノードがフラッディング攻撃を開始し、次いでネットワークを離れている場合には、プロキシノードは、自身が第1のノードに代わって動作する権限を有することを第3のノードに示すことができ、次いで、第3のノードは、第1のノードに関するすべてのバインディングキャッシュエントリ(Binding Cache Entries)を削除することによって、フラッディング攻撃を停止することができる。]
[0019] 本発明の第2の態様に従えば、通信ネットワークで使用するためのノードが提供される。このノードは、第2のノードに属する暗号化属性の少なくとも一部を第2のノードから受信するための受信器と、受信した第2のノードに属する暗号化属性の少なくとも一部と、そのノードに属する暗号化属性の少なくとも一部とを使用して、そのノードのための識別子を生成するためのプロセッサとを備えており、それによって、そのノードと第2のノードとの間の暗号化関係を確立する。]
[0020] オプションで、この識別子は、暗号化によって生成されたIPアドレスであり、そしてこの暗号化属性は、第2のノードに属する公開鍵であってもよい。]
[0021] ノードは、オプションで、第2のノードに属する暗号化属性をランダム値と連結するための手段と、連結された結果をハッシュするための手段と、そして、結果として得られたハッシュ値の少なくとも一部をそのノード用の識別子を生成するための修飾子として使用するための手段とを備える。]
[0022] 本発明の第3の態様に従えば、通信ネットワークで使用するプロキシノードが提供される。このプロキシノードは、プロキシノードに関連付けられている第1のノードの識別子を記憶するためのメモリを備え、その識別子は、プロキシノードに属する暗号化属性の少なくとも一部と、第1のノードに属する暗号化属性の少なくとも一部とを使用して、生成されているものである。プロキシノードは、さらに、識別子と、識別子を生成するために使用される暗号化材料とを次のノードへ送信するための送信器を備える。次いで、この識別子と暗号化材料とは、プロキシノードが第1のノードに代わってメッセージを送信する権限を有することを検証するために、次のノードによって使用されることができる。]
[0023] オプションで、この識別子は、暗号化によって生成されたIPアドレスであり、そして、暗号化属性は、プロキシノードに属する公開鍵である。]
[0024] オプションとして、プロキシノードは、さらに、第1のノードに関するフラッディング攻撃を検出するための手段と、次のノードにフラッシュリクエストメッセージを送信するための手段とを備える。このフラッシュリクエストメッセージは、第1のノードに関するすべてのバインディングキャッシュエントリ(Binding Cache Entries)をフラッシュすることを次のノードに命令するものであり、このフラッシュリクエストメッセージは、第1のノードに属する識別子と、識別子を生成するために使用されるその他の暗号化材料とを含んでいる。このようにして、第1のノードがフラッディング攻撃を開始し、次いでネットワークを離れる場合、プロキシノードは、自身が第1のノードに代わって動作する権限を有することを第3のノードに示すことができ、次いで、第3のノードは、第1のノードに関するすべてのバインディングキャッシュエントリ(Binding Cache Entries)を削除することによって、フラッディング攻撃を停止させることができる。]
[0025] 当業者には明らかであろうが、第1のノードの識別子には、そのIPアドレス、ノード名、またはノードに関連付けられている他のタイプのアドレスを含んでいてもよい。例えば、R.Moskowitz他、draft−ietf−hip−base−10、IETFによるホストアイデンティティタグ(Host Identity Tag(HIT))が識別子として使用されてもよいだろう。]
図面の簡単な説明

[0026] プロキシモバイルIPv6アーキテクチャをブロック図で概略的に示す図である。
暗号化によって生成されたIPアドレスパラメータを概略的に示す図である。
本発明の第1の実施形態の基本ステップを示すフロー図である。
本発明の一実施形態に従うホームエージェントと対向ノードとの間のバインディングを確立するためのシグナリングを概略的に示す図である。
本発明の実施形態に従うネットワークノードを概略的に示すブロック図である。
本発明の一実施形態に従うプロキシノードを概略的に示すブロック図である。]
実施例

[0027] 以下の記載は、例えば、特定の実施形態、手順、技術等のような具体的詳細について、限定する目的ではなく説明を目的として説明する。場合によっては、周知の方法、インタフェース、回路およびデバイスの詳細記載は、不要な詳細で記載をあいまいにしないようにするために省略する。また、一部の図面では、個別のブロックが示される。これらのブロックの機能は、個別のハードウェア回路を使用して、適切にプログラムされているデジタルマイクロプロセッサまたは汎用コンピュータと協働するソフトウェアプログラムおよびデータを使用して、または、特定用途向集積回路を使用して、および/または、1つ以上のデジタル信号プロセッサを使用して実装されてもよいことが理解されるであろう。]
[0028] 高いレベルでは、本発明は、以下の特徴を有する方法について記載する。]
[0029] 1.第1のステップで、MNは、MNの属性(例えば、自分のIPアドレスのような識別子)に関連付けられている一定のタスクを快くプロキシに委任することを示している。この目的を達成するために、MNは、プロキシの一部の属性(例えば、プロキシの公開鍵)に依存して、対応する属性を生成する。これは、第三者が委任を(効率的に)検証できるように、かつ、MNが一定の責任を特定のプロキシに委任していることに疑問の余地がないように、暗号化によって「バインディングする」方法で行われる。例えば、MNは、対応するMNの属性を変更することなく、別のプロキシに委任していることは主張することはできない。例えば、MNの属性は、暗号化ハッシュ関数をプロキシの属性(の少なくとも一部)に適用する結果として生成される。]
[0030] 2.第2のオプションのステップで、プロキシはMNの委任の検証を行い、そして、プロキシが委任されたタスクを受け入れる場合、プロキシは、プロキシの属性とMNの属性との間のバインディングの公的に検証可能な証明(プルーフ)を発行する。このプルーフは、例えば、MNの属性の電子署名によって実行されてもよいだろう。]
[0031] ステップ2が実装される場合、できれば前記プルーフの中に第三者によって供給される「ナンス(nonce)」を含めることによって、第三者が委任の有効性を検証することを要望する度に実行されることが望ましい。]
[0032] また、プロキシに委任されるタスクの「範囲」も、MNの属性の生成の中に含まれてもよいだろう。その後、どのタスクをMN/プロキシが委任することに合意しているのかを正確に検証できるように、この範囲が、機械が読み取れる形式でまたは人間が読み取れる形式で含まれることが好ましい。その他の場合では、どのタスクが委任されているかの「暗黙の」了解が存在してもよい。例えば、属性がMNのIPアドレスである場合、委任のデフォルトの範囲は、MNに代わってシグナリングをプロキシすることであってもよいだろう。]
[0033] 本発明の第1の実施形態では、移動ノード(MN)についての暗号化によって生成されたアドレス(CGA)を生成するための新たな手法が提供される、すなわち、MNの属性はCGAである。MNは、ホームエージェント(HA)を有しており、MNは、MNについてのIPv6ホームアドレスの64ビットのインタフェース識別子(IID)を生成する場合、HAの公開鍵(HKp)を含んでいる。MNのIPv6ホームアドレスの中にHKpを含める方法の一例は以下の通りである。]
[0034] RFC3972に記載されるCGA手法では、MNは、修飾子(MD)と呼ばれるランダムの128ビットパラメータを導出する。ネットワークプレフィックスやMNのCGA公開鍵(Public Key)(Kp)のような他のパラメータのうちで、64ビットIDを生成するためにMDが使用される。図2に、CGAパラメータが示されている。本発明の第1の実施形態に従えば、HKpをランダムの128ビット値(例えば、先行技術のCGAにおけるMDの値)と連結し、次いでその結果をハッシュすることによってMDを生成する場合に、HKpが使用される。結果として得られるハッシュ値の先頭の128ビットが、新たなMDとして使用される。これは、以下のように表すことができる。] 図2
[0035] 新たなMD=先頭の[128,Hash(HKp|RAN(128))]
ここで、「RAN(128)」は、ランダムな128ビットのパラメータである。]
[0036] 同一の「新たなMD」を生成する多くの値(HKp、RAN(128))が存在しうるだろうから、暗号化(耐コリジョン(衝突)性の)ハッシュ関数が使用される場合、(MNまたは、プロキシを含むいずれかの他の当事者が)同一のMDを与える別の(HKp、RAN(128))ペアを見つけることは、演算的に実行不可能であると想定することができる。RANパラメータの長さは、128ビットより長いことも短いこともありうるだろう。RANパラメータの主たる目的は「新しさ」を提供することであるから、たとえ同一のHKpが使用される場合でも、同一の新たなMDを常に(再)生成する可能性は低い。また、MNは、RANをリモートノードに開示して、自身はプロキシノードが自身に代わって動作することに合意していることを、さらに証明することができる。]
[0037] 図2で「修飾子」201は、128ビットの符号なし整数を含むフィールドであり、それはいかなる値であってもよいことに注意されたい。この修飾子は、ハッシュの拡張部分を実装するため、かつ、ランダムさをアドレスに加えることによってプライバシを向上させるために、CGA生成の間に使用される。しかしながら、MNの公開鍵もまた必要であり、従って、MNを「追跡する」ために使用されうることから、完全なプライバシは不可能であることに注意されたい。] 図2
[0038] このメカニズムは、MNのIPv6アドレスをそのHAの公開鍵に「バインディング」させ、それによって、MNとそのHAとの間の「暗号化」関係を構築する。IPv6アドレスとHKpとのこのバインディングが一旦行われると、他のノードは、RAN(128)パラメータを使用することができる場合であって、かつ、IPv6アドレスを生成するために必要とされるすべてのパラメータを自身が提供できるように装うことができる場合であっても、この特定のアドレスとの同様の関係を主張することができない。悪意のあるノードは、この特定のアドレスに関連付けられているMDを生成する際に使用されるMNの公開鍵の「所有権」を示す必要があるであろう。所有権を示すためには、悪意のあるノードは、公開鍵に対応する秘密鍵の知識を必要とするであろうし、これは明らかに実行不可能である。ここで、これはMNの公開鍵のことを言うことに注意されたい。HAが関係を「証明する」ことを第三者から求められる場合、HAは、(その秘密鍵/公開鍵を用いて)RAN(128)パラメータに署名することによって、これを行うであろう。この場合、関係を構築することは、HAの秘密鍵の知識を意味するであろう。]
[0039] さらに、暗号化関数の適切な選択によって、悪意のあるノードが既存のIPv6アドレスとの暗号化関係をエミュレートすることは、同一のIPv6アドレスを生成することを目的として自分自身の公開鍵に合致するCGAパラメータを見つけ出すことが必要であることから、演算的に実行不可能であると想定することができる。従って、暗号化関係は一意であるとみなしうることになる。]
[0040] MNについてのIPv6アドレスを生成する基本ステップを図3に示すが、それは以下の通りである。] 図3
[0041] 301. MNがHAの公開鍵であるKpを取得する。]
[0042] 302. Kpが、例えば、MNによってランダムに選択された、ランダムな128ビット値(128)と連結される。]
[0043] 303. 連結された結果がハッシュされる。]
[0044] 304.ハッシュ値の先頭の128ビットが、修飾子MDとして使用される。]
[0045] 305. MNについてのCGAを生成するためにMDが使用される。]
[0046] 本発明の第2の実施形態に従えば、MNのためのルート最適化(Route Optimization:RO)を提供するために、MNとHAとの間の暗号化関係が利用されてPMIPv6環境に適用される。]
[0047] HAは、上記の第1の実施形態で説明される公式に応じて生成されるものではないホームアドレスを搬送するものであるならば、MNまたはその対向ノード(Correspondent Node:CN)によって送信された、いかなるホームテストイニト/ホームテスト(Home Test Init/Home Test)(HoTI/HoT)メッセージをも破棄する。これは、自分自身のCGAホームアドレスを生成する時には、HAによってサービスが提供されるすべてのMNがHAの公開鍵であるHKpを使用しなければならないことを必要とする。]
[0048] MNは、自身のHAが、MNのCGAホームアドレスの所有権を、それをRAN(128)およびそのHKpにバインディングさせる前にチェックすることを可能にする(すなわち、新たなMDを生成するために、両方のパラメータが使用される)。アドレスの所有権が有効であることが一旦証明され、かつ、HKpとRAN(128)とMNのホームアドレスとの間のバインディングが一旦完了すると、HAは、MNとHKpとの間に関係があることを証明することができ、そして、それは、信頼の証拠をCNに提供して、直接MNと通信しなくてもMNにサービス提供するMAGと直接通信することでMNにサービス提供することをCNに促す。本発明の一実施形態では、アドレスの所有権を証明することは、HAが少なくともRAN(128)に署名することと、CNによって提供されるナンスとによって実行される。ナンスは、悪意のあるCNがすでに取得されている署名を使用して、それを他のCNに対して「再生」することを防ぐという点で、有益である。オプションで、HAがCNとの共有鍵を有する場合、この共有鍵がHAの公開鍵/秘密鍵ペアの代わりに使用されてもよいだろう。]
[0049] 図4は、リターンルータビリティ(Return Routability)(RR)手順のためのシグナリングをしている。その手順において、HA401は、CN402との長期間のセキュリティ関係を確立する。CN402は、HA401と現在MNにサービスを提供しているMAG403との間で双方向トンネリング(Bidirectional Tunneling:BT)モードを使用してデータパケットをMNとすでに交換している。図4の番号を使用すると、ステップは、以下の通りである。] 図4
[0050] S1. MNの現在のMAG403によって送信される有効なプロキシバインディング更新(Proxy Binding Update)(PBU)メッセージの受信に続いて、MNのHA401は、(例えば、特定のトラフィック/フローについて)ROモードのサービスをMNに提供するための決定を行う。HA401は、HoTIメッセージをCN403へ送信する。HoTIメッセージには、「デュアルアドレス(Dual Address)(DA)」と呼ばれる新たなオプションを有しており、これは、MAG403によって送信される新たなCoAをHA401へ搬送する。ここ、CoAは、さまざまな手段を使用して送信されうる。例えば、CoAは、PBUメッセージの中で搬送される特定のホームアドレスについてROモードをトリガするか否かというHA401の決定に関らず、PBUメッセージの中で搬送されるオプションとしてMAG403へ送信されてもよいだろう。HoTIメッセージに挿入されるDAのオプションは、ホームキージェネレータトークン(Home Keygen Token)(HoToK)を演算する場合にCN402がCoAを含めるための特別なリクエストを構築する。CN402へ送信されるHoTIメッセージで使用されるIPv6ソースアドレスは、HA401に属していなければならず、そのHKpを使用して導出されるCGAアドレスであるべきである。]
[0051] DAのオプションを導入することによって、HA401は、悪意のあるノードによって送信されるHoTIメッセージを検出することができ、ここで、その悪意のあるノードとは、HAと「暗号」関係を確立しているが、ネットワークに対してまたはCN402自身に対してフラッディング攻撃を仕掛けることを目的としてCNとの特別なバインディングを確立しようとしているノードである。HA401は、特定のCN402との特別なバインディングを確立することが許可されている唯一のエンティティであり、それによって、MNにROモードサービスを提供することを目的としてMNと自身との「暗号」関係を使用することが可能になる。]
[0052] S2. また、HoTI/HoTメッセージのペアをCN402と交換することと並行して、MAG/LMA403が、MNのためのROモードをトリガすることを目的としてRR手順を完了する際にMNのHA401を支援してもよい。この場合、MAG/LMA403は、気付アドレスイニット/気付アドレステスト(Care−of Address Init/Care−of Address test)(CoTI/CoT)メッセージのペアをCN402と交換することによって、かつ、それに対する返信として気付キージェネレータトークン(Care−of Keygen Token)(CoTok)を受信することによって、HA401へ送信されるCoAについてのアドレス到達性テストを実行する。HA401がROモードの完全な制御を維持することを保証することを目的として、HA401は、CoTI/CoT交換を実行する。これのために、HA401は、CoTIメッセージをMAG/LMA403へトンネルし、次に、MAG/LMA403は、CoTIメッセージのカプセルを除去して、それをCN402へ転送する。CN402は、MAG/LMA403にリプライし、従って、このリプライが、次に、HA401へトンネルによって戻される。]
[0053] S3.HA401によって送信されるHoTIメッセージを受信した後、CN402は、HoTokを搬送するHoTメッセージを送信することによってリプライする。CNはステートレスのままである。]
[0054] S4. MAG/LMA403から転送されるCoTokを受信すると、HA401は、RFC3775に記載されるように、一時的な共有シークレット(秘密)(Ks)を生成することを目的として、CN402から受信されるHoTokとCoTokとを組み合わせる。次いで、HA401は、(Ksでそれを認証することに加えて)自身の秘密鍵で署名されるBUメッセージを送信して、CN402に対して所有権のプルーフ(証明)を提供することを目的として、すべてのCGAパラメータを(すなわち、HKpを含めて)BUメッセージに挿入する。HA401は、HoTokがHAのIPv6アドレスとCoAとの両方を使用して生成されていることをCN402に催促することを目的として、新たなビットをBUメッセージ内に設定することを必要とすることがある。また、新たなビットは、HAアドレスのプレフィックス部分だけをCoAにバインディングするようCN402にリクエストする働きをする。これは、バインディングは64ビットのプレフィックスと通常のIPv6アドレスとの間で行われるであろうから、従って、普通なら悪意のある盗聴ノードによって悪用される可能性があったはずの、2つのノード間のデータパケット交換をもたらさないであろうということを意味する。]
[0055] S5. 有効なBUメッセージを受信した後、CN402は、長期間のシークレット(秘密)(Kbm)を生成し、HKpを使ってそれを暗号化し、そして、それをバインディング確認応答(Binding Acknoeledgement)(BA)メッセージの中でHA401へ返信する。ここで、バインディング応答確認(Binding Acknowledgement)(BA)メッセージもまた、Ksを使って認証される(そして、CNのCGA鍵を使って署名されうる)。また、CN402も、HAアドレスのプレフィックスとCoAとの間のリクエストされたバインディングが成功していることをHA401に示すことを目的として、「プレフィックスバインディング(Prefix Binding)(PB)」と呼ばれる新たなビットを設定する。CNは、HAの公開鍵(すなわち、HKp)を、Kbm、HAのIPアドレスのプレフィックス、CoA、およびCNのIPアドレスと一緒に、対応するバインディングキャッシュエントリ(Binding Cache Entry)(BCE)の中に記憶する。]
[0056] S6.HA401は、有効なBAメッセージをCN402から受信すると、「リンク化ホームアドレス(Linked Home Address)(LHA)」のオプションと呼ばれるオプションの中で、MNのホームアドレスを含む新たなBUメッセージをCN402に送信する。HA401は、(RAN(128)値を含む)自身のIPv6アドレスをHKpから導出するために、MNによって使用されているすべてのCGAパラメータを含んでいる。HA401は、Kbmを使用してBUメッセージを認証する。HA401とMNとの間の関係を示すことによって、(MNアドレスプレフィックスと同一である)HAアドレスプレフィックスとCoAとの間に構築されるバインディングにMNのホームアドレスを追加することを、CN402に対してリクエストするために、このBUメッセージが使用される。]
[0057] HA401は、自身がMNによって使用されるプレフィックスと同一のプレフィックスで到達可能であることをすでにCN402に示しているので、MNのホームアドレスを使用してHoTI/HoTメッセージをCN402と交換する必要はない。しかしながら、CoTI/CoTの交換は、MNとの「暗号化」関係を有するHA401が、MAGインタフェースに割り当てられているCoAに対応するCoTokをいつでも捕捉することができるということをCN402に証明するために有用である場合がある。この場合、HAは、ステップS4のBUメッセージの中でCoTokを送信する。これは、それを新たなオプションの中に挿入することによって、または、それをKbmとマージすることによって、のいずれか一方によって行うことができる。また、後者の場合、CN402は、ステップS5でHA401へ送信されるBAメッセージを認証するためにも、同一の新たな鍵を使用するべきである。MNが別のMAGへ移動していないのならば、CoTI/CoTの交換を周期的に繰り返す必要はない。]
[0058] 上記の実施形態への代替案では、第2のBUメッセージの内容が第1のBUメッセージに含まれる。HA401は、MNのHoAだけでなく、RAN(128)値も含む、そのCGAパラメータも、リターンルータビリティ(Return Routability)(RR)手順に続いてCN402へ送信される第1のBUメッセージに挿入する。MNのHoAとの「暗号化」関係のプルーフ(証明)を提供することによって、HA401は、MNに代わって実行されうる任意のRR手順についてもHoTokとCoTokとを捕捉することもできるということを、暗示的にCN402に示唆する(ここで、そのようなRRでは、HoTIメッセージは、MNのHoAをソースアドレスとして使用するであろうし、そして、HoTメッセージはMNのHoAへ送信されるであろうし、そして、CoTI/CoT交換には、HA401によって使用されるCoAと同一のCoAを含むであろうことに注意されたい。)この場合、HA401によって使用されるもの以外には、いかなる追加のCoTI/CoTメッセージを交換する必要もない。]
[0059] ここで、悪意のあるノードが、自身の制御下にある他のノードの各々と「暗号化」関係を有することを目的としてそれらを構成することが可能であることに注意されたい。この関係は、ネットワーク/ノードに対する攻撃を開始するために、後で利用されうる。MIPv6および/またはPMIPv6環境において、最初の、かつ、重要な防衛線は、悪意のあるノードがCN402とのプレフィックスバインディングを確立し、次いで、自身の制御下にあるすべてのノードを同一のCoA402にリダイレクトするという攻撃のいかなる可能性をもHA401が阻止することを要求する。それを行うためには、攻撃者は、上述の新たなDAオプションを搬送するHoTIメッセージを送信する必要があるであろう。このオプションはRR手順の全般的なセキュリティを向上させる一方で、HA401が、単純にHoTIメッセージを調べることによって、非常に初期の段階で攻撃を検出することも可能にする。この攻撃は、パケットを破棄することによって阻止される。]
[0060] また、訪問先ネットワークが、フラッディング攻撃を撃退することもできる。MIPv6プロトコルに従えば、ネットワークのフラッディング攻撃に対抗する防衛策の1つは、リターンルータビリティ(戻り経路可能性)手順を周期的に(例えば、7分おきに)繰り返すことである。MNが移動中でない場合であっても、上記のHoTI、HoT、およびCoTI/CoTシグナリングの交換が周期的に実行される。これには、かなりの量のシグナリングが必要である。]
[0061] 悪意のあるノード(MN)が、ネットワークに対してフラッディング攻撃を仕掛けることがある。一旦攻撃が検出されると、MAG/LMA403は、認証されるシグナリングメッセージをHA401がCN402へ送信して、BCE(群)に対応する悪意のあるノード(群)をフラッシュ(flush)することを、CN402に明示的にリクエストする。また、「撃退」タイプの防衛策を、MAG/LMA403に完全に実装することもでき、その場合、MAG/LMA403は、HA401を経由せずに、直接CN(群)402へ「フラッシュリクエスト」メッセージを送信する。これは、バインディングが確立された後でHA自身が改ざんされるような状況において、有益である。この場合、MAG403は、CN402を使ってCoAテストを実行し、次いで、特別な「バインディングフラッシュリクエスト(Binding Flush Request)」を送信する。バインディングフラッシュ(Binding Flush)リクエストメッセージは、MAGとMNとが暗号化関係を有するというプルーフ(証明)と一緒に、MNのCoAを含んでおり、従って、MAGの秘密鍵を使って署名されている。]
[0062] フラッシュリクエストを受信すると、まず、CN402は、対象のCoAがCNのバインディングキャッシュエントリ(Binding Cache Entry)(BCE)テーブルに記憶されていることを確認する。MAGがMNに代わって動作する権限を有することを一旦検証すると、CNは、MNのCoAをそのBCEテーブルからフラッシュし、そして、そのCoAを使用しているすべての進行中のセッションを終了させる。また、CNは、フラッシュ確認応答をMAGへ送信する。]
[0063] 本発明の別の実施形態に従えば、2つのノード間の暗号化関係は、MNがセキュア近隣ディスカバリ(Secure Neighbor Discovery)(SeND)プロトコルの責任を、例えば、アクセスルータ(Access Router)(AR)のようなプロキシノードに委任することを可能にすることができる。SeND(2005年3月のRFC3971、J.Arkko、J.Kempf、B.Sommerfield、B.ZillおよびP.Nikander著「セキュア近隣ディスカバリ(Secure Neighbor Discovery)(SeND)」を参照されたい。)によって、同一のリンクに接続するホスト間、および/または、ホストとそのアクセスルータ(AR)群間の関係を確立できるようになる。SeNDは、ホスト側でIPv6CGAを使用し、そして、アクセスネットワークにはローカルな公開鍵インフラストラクチャを展開する。]
[0064] SeNDプロトコルを使用して、すべてのルータ広告(RtAdv)メッセージだけでなく、ARによって送信される(2007年9月のRFC4861、T.Narten、E.Nordmark、W.SimpsonおよびH.Soliman著「IPバージョン6用の近隣ディスカバリ(Neighbor Discovery for IP version 6)(IPv6)」の中で記載される)いかなる近隣ディスカバリプロトコルメッセージも、署名される。加えて、いかなるホストも、CGAベースのIPv6アドレスを構成することができ、そして、同一のリンクに位置する他のホストと近隣ディスカバリプロトコルメッセージを交換する場合には、そのプロパティを使用して「所有権のプルーフ(証明)」を提供することができる。]
[0065] 上述のように、2つのノード間の暗号化関係を使用することによって、CGA IPv6アドレスを使用するホストは、SeNDのタスクを委任して、そのARにプロキシすることができる。]
[0066] CGA対応ノードが、ARがSeNDを使用してそのRtAdvメッセージに署名しているリンクに接続する場合、ノードは、ARの公開鍵(Kp)のコピーをセキュアな方法で取得して、ノードとARとの間の暗号化関係を確立することができる。128ビットのランダムパラメータが、ノードのCGA IPv6アドレスを再演算するために使用される。ノードがARとの暗号化関係を確立できるようにするためには、128ビットのランダムパラメータの修正が必要である。128ビットのランダムパラメータは、ランダムパラメータ(例えば、128ビットまたは256ビット)を生成した後に、このパラメータをARのKpと連結して、その後連結をハッシュすることによって作成される、別のパラメータと置換される。次いで、ノードは、結果として得られるハッシュの先頭の128ビットを切り取って、それを新たなランダム128ビットパラメータとして使用して、そのCGA IPv6アドレスの64ビット識別子を生成する。]
[0067] 新たな128ビットのランダムパラメータを演算するためのルールは、以下で表すことができる。]
[0068] 新たなCGA 128ビットランダムパラメータ=先頭の[128,Hash(Kp|RAN(128)]
ここで、先頭の(サイズ、入力)は、「入力」データの先を切ることを示し、従って、先頭の「サイズ」ビットだけが依然として使用される。RAN(z)はzビットのランダムパラメータであり、「|」は、連結を示している。推奨されるハッシュ関数はSHA256である。]
[0069] 新たな128ビットパラメータを演算した後、ノードは、CGA仕様に定義されるような自身のIPv6アドレスを演算することへと進む。しかしながら、ノードは、ARに暗号化関係に気付かせることを目的として、RAN(128)をそのARへ送信しなければならない。ノードは、RAN(128)を、搬送されることになる新たなオプション(SROと呼ばれる)に、例えば、ARに送信されるルータ要請(RtSol)メッセージに挿入することができる。セキュリティを加えるために、ノードは、ARのKpを使用してSROを暗号化する。]
[0070] SROを搬送するRtSolメッセージを受信すると、ARは、まず、暗号化関係の有効性をチェックする。SROは復号されることが好ましく、そして、ARは、CGA IPv6アドレスがARのKpを使用して生成されたことをチェックする。ARが、CGA IPv6アドレスがARのKpを使用して生成されたと判定する場合には、ARは、アドレスの所有権をチェックして署名を検証することへと進む。その後、ARは、ノードのRAN(128)を、そのアドレスおよびすべての関連するCGAパラメータと一緒に記憶する。]
[0071] ノードが、暗号化関係をそのARに明かさないことを決定する場合には、ノードは、その新たな128ビットのCGAパラメータだけをARに開示することによって、SeNDを使用し続けることができる。]
[0072] ARが、自身がMNに替わって動作する権限を有することを第三者に証明することが必要な場合、ARは、「関係のプルーフ(証明)」を提供するために、暗号化関係を第三者に開示する。これは、MNのIPv6アドレスと、それを生成するためにMNが使用しているすべてのCGA成分とを、第三者に通知することによって行われる。これらの成分には、128ビットのランダムパラメータの代わりにRAN(128)値を含んでいる。加えて、ARは、この情報を含む、第三者へ送信されるメッセージに署名する。また、ARは、この署名の中に、第三者によって提供されるナンスも含んでいることが好ましい。いかなる他のノードも、署名を偽造できない限り、ノードに代わって動作するという同一の特権を主張することはできないし、そのような署名の偽造は実行不可能だと想定されうる。また、悪意のあるノードが別の鍵ペアを生成して、MNによって使用される同一のIPv6アドレスをもたらすようなパラメータの連鎖全体を再構築することを試行することも実行不可能であると想定されうる。]
[0073] 非CGA移動ノードとの暗号化関係を使用することは可能であるかもしれない。MNは、上述のルールと同一のルールではあるが、先頭の64ビットを取り出してそれらをIPv6アドレスを構成するためのインタフェース識別子として使用する必要があるという点で違いがあるようなルールを適用することによって、そのIPv6アドレスを導出する。この状況に従えば、ホストがRtSolメッセージをARへ送信する。ここで、ホストはSROを含んでおり、それをATのKpで暗号化する。ここで、RtSolメッセージは、この場合は署名されないであろうが、移動ノードは、ARがソースアドレスの有効性をチェックできるようにすることを目的として、64ビットのインタフェース識別子をIPv6ソースアドレスの中に使用することに注意されたい。このサービスは、近隣ディスカバリプロキシ実行タスクをそのARに委任することを可能にすることから、低処理力のデバイスにとって有益でありうる。]
[0074] 暗号化関係は、ステートフルなアドレス構成が行われている場合、すなわち、MNが自身のアドレスを自由に選択しない場合、MNとそのARとの間で自動的に確立されてもよい。これは、リンクに接続しているMN群に割り当てられることになるIPv6アドレスを生成するためにDHCPを可能にすることによって、行われてもよい。次いで、DHCPは、MNに関与させることなく、RAN(128)をARと共有する。この状況では、ARは、RtAdvメッセージの中に1ビットを設定することによって、MNに代わって動作するその能力をMNに信号で伝達してもよい。]
[0075] 上述のように、暗号化関係は、SeNDプロキシ実行を移動/固定ホストが行えるようにするために使用することができる。そのようにするためには、各MNは、そのARと暗号化関係を確立し(すなわち、その証明をチェックした後で)、次いで、対応するRAN(128)パラメータをそのCGAパラメータと一緒に、ARへ送信しなければならない。ここで、SeND近隣ディスカバリプロトコル(NDP)プロキシ実行タスクをARへ委任する1つの方法は、暗号化関係を、MNによって送信されうるRtSolメッセージの中でARに開示することである。SROを搬送するRtSolメッセージを送信した後で、送信ノード(すなわち、プロキシノードと暗号化関係を確立しているノード)が、近隣ディスカバリプロトコルのクエリへの応答を中止する。換言すれば、送信ノードが、自身が適切であると判断する時にはいつでも、リンクから「消える」時を決定する。]
[0076] プライバシ目的のために、MNは、NDPメッセージに署名する場合に自分自身のCGA公開鍵を公開することを避けることを目的として、リンクに物理的に接続している間であってもプロキシ実行タスクを自身のARに委任することを決定してもよい。実際、特にMNが1つ以上の擬似IPv6アドレスを使用している場合に、公開鍵を開示することは、匿名性(unlinkability)の側面を大きく損なう可能性がある。異なるAR間をMNが切り替わる場合、MNは、普通ならCGA公開鍵を開示することによって損なわれるはずの、ある程度の位置プライバシを維持することを望む可能性がある。]
[0077] 特定のホストに代わってSeNDプロキシとして動作する場合、ARは、NDPメッセージの有効性をチェックする前に、第三者ノードがARのKpを使用してMNのIPv6アドレスを導出できるようにするために、MNに代わって送信される各NDPメッセージの中に、RAN(128)値だけでなくMNのCGAパラメータすべてを含ませる。第三者ノードが、提供されるMNのIPv6アドレスをARによって送信されるパラメータから演算できない場合、第三者ノードはメッセージを破棄する。]
[0078] 暗号化関係を構築するために有益でありうるもう1つの設定は、ホストアイデンティティプロトコル(Host Identity Protocol)(HIP)のコンテキストにある。ここで、(移動)ノードは、ホストアイデンティティタグ(Host Identity Tag)(HIT)属性を有する。このホストアイデンティティタグ(Host Identity Tag)(HIT)属性は、ノードの公開鍵をハッシュすることによって生成される、すなわち、HIT=HASH(...,PKn,...)である。また、上述の諸実施形態と同様に、ノードは、HITを作成する時に何らかの他のエンティティの公開鍵も含んでいる。一般に、ノードが一時的な「識別子」または他の属性を生成する場合に、本発明を使用することができる。例えば、EAP(拡張認証プロトコル(Extensible Authentication Protocol)、IETF RFC 3748)雅号またはGPRS P−TMSIが、この方法に従って生成されてもよい。また、本発明によって(一時的な)「アカウント番号」を生成することによって「金融」取引を委任することも可能である。]
[0079] 上述のすべての実施形態に従えば、プロキシノードが不正に振舞って、実行されるべきでない行為を第1のノードに代わって実行することには利点が存在する可能性があることから、第1のノード(例えば、移動ノード)によって供給されるRANは、それ自体で、第1のノードに代わってプロキシノードが動作しているという絶対的なプルーフ(証明)を構築しない。また、そのような場合、第1のノードは、IPアドレスを生成するためにその公開鍵も使用しなければならず、従って、第1のノードは、プロキシノードが移動ノードに代わって動作する権限を有することを第3のノードが検証することを目的として、その公開鍵も第3のノードに提供しなければならない。]
[0080] 次に図5を参照すると、ここでは本発明の一実施形態に従うネットワークノード501が示されている。この例では、ネットワークノードは、移動ノード501であり、そして、移動ノードに関連付けられているプロキシノードの公開鍵を受信するための受信器502と、MNについての暗号化によって生成されるIPアドレスを生成するためのプロセッサ503とを備える。移動ノードは、さらに、プロキシノードと通信するための送信器504と、生成されるIPアドレスを記憶するためのメモリ505とを備える。] 図5
[0081] 図6は、プロキシノード601を示している。ここで、プロキシノード601は、プロキシノードに関連付けられているMNに属する識別子を記憶するためのメモリ602を備えており、この識別子は上述のようにして生成されているものである。識別子と識別子を生成するために使用される暗号材料とこれらの値の署名とを次のノードに送信するために第1の送信器603が提供され、それによって、プロキシノードが第1のノードに代わってメッセージを送信する権限を有することを、次のノードが検証できるようになる。署名を作成するために第1の処理機能604が提供され、そして、署名を次のノードに送信して、プロキシノードが第1のノードに代わってメッセージを送信する権限を有することを次のノードが検証できるようにするために、第2の送信器605が提供される。] 図6
[0082] 各種の実施形態を示し、詳細に記載してきているが、請求項は、いずれかの特定の実施形態や例に限定されるものではない。上述の記載はいずれも、いずれかの特定の要素、ステップまたは機能が、それが請求項の範囲に含まれなければならない程度に必須であることを意味していると解釈されるべきではない。特許で保護される範囲は、請求項によって定義される。]
[0083] 本明細書では、下記の頭字語が使用される。]
[0084] BAバインディング応答確認(Binding Acknowledgment)
BCEバインディングキャッシュエントリ(Binding Cache Entry)
BT双方向トンネリングモード(Bidirectional Tunneling Mode(MIPv6))
BUバインディング更新(Binding Update)
CGA 暗号化生成アドレス(Cryptographically Generated Address)
CN対向ノード(Correspondent Node)
CoT気付アドレステストメッセージ(Care-of Address Test Message)
CoTI 気付アドレスイニットメッセージ(Care-of Address Init Message)
CoTok 気付キージェネレータトークン(Care-of Keygen Token)
HAホームエージェント(Home Agent)
HKp ホームエージェント公開鍵(Home Agent public key)
HKr ホームエージェント秘密鍵(Home Agent private key)
HoTホームテストメッセージ(Home Test Message)
HoTI ホームテストイニットメッセージ(Home Test Init Message)
HoTokホームキージェネレータトークン(Home Keygen Token)
IETFインターネットエンジニアリングタスクフォース(Internet Engineering Task Force)
Kp移動ノードCGA公開鍵(Mobile Node CGA public key)
Ks HAとCN間の共有鍵(Shared Key between the HA and the CN)
LMAローカルモビリティアンカー(Local Mobility Anchor)
MAG移動アクセスゲートウェイ(Mobile Access Gateway)
MD修飾子(Modifier)
MIPv6 (Mobile IPv6)
MN 移動ノード(Mobile Node)
NDP近隣ディスカバリプロトコル(Neighbour Discovery Protocol)
PMIPv6プロキシMIPv6(Proxy MIPv6)
ROルート最適化モード(Route Optimization Mode(MIPv6))
RRリターンルータビリティ手順(Return Routability Procedure)
PBUプロキシバインディング更新メッセージ(Proxy Binding Update Message)
SeNDセキュア近隣ディスカバリ(Secure Neighbor Discovery)]
权利要求:

請求項1
通信ネットワークにおいて、第1のノードと第2のノードとの間で暗号化関係を確立する方法であって前記第1のノードで、前記第2のノードから、該第2のノードの暗号化属性の少なくとも一部を受信するステップと、前記第1のノードの識別子を生成するために、受信した前記暗号化属性の少なくとも一部と、前記第1のノードの暗号化属性の少なくとも一部とを使用するステップとを備えることを特徴とする方法。
請求項2
前記第1のノードの識別子は、暗号化によって生成されたIPアドレスであることを特徴とする請求項1に記載の方法。
請求項3
前記暗号化属性は、前記第2のノードに属する公開鍵を備えることを特徴とする請求項1または2に記載の方法。
請求項4
前記第1のノードにおいて、前記第2のノードに属する前記暗号化属性をランダム値と連結するステップと、連結された結果をハッシュするステップと、結果として得られたハッシュ値の少なくとも一部を前記第1のノードの識別子を生成するための修飾子として使用するステップとを更に備えることを特徴とする請求項1乃至3のいずれか1項に記載の方法。
請求項5
前記第2のノードにおいて、前記第1のノードに属する前記識別子と前記ランダム値とを第3のノードへ送信するステップと、前記第3のノードにおいて、前記第2のノードが前記第1のノードと信頼関係を有することを検証するために、前記第1のノードに属する前記識別子と前記ランダム値とを使用するステップとを更に備えることを特徴とする請求項4に記載の方法。
請求項6
前記第2のノードにおいて、前記第1のノードに属する前記識別子と前記ランダム値とを含むメッセージに署名するステップを更に備えることを特徴とする請求項5に記載の方法。
請求項7
前記通信ネットワークは、プロキシモバイルIPネットワークを備え前記第1のノードは、移動ノードであり、前記第2のノードは、前記移動ノードに関連付けられているホームエージェントであることを特徴とする請求項1乃至6のいずれか1項に記載の方法。
請求項8
前記ホームエージェントを介して、前記移動ノードにルート最適化を提供するステップを更に備えることを特徴とする請求項7に記載の方法。
請求項9
前記第1のノードは、移動ノードであり、前記第2のノードは、それを介して前記移動ノードが前記通信ネットワークに接続するプロキシノードであることを特徴とする請求項1乃至6のいずれか1項に記載の方法。
請求項10
前記移動ノードに代わって前記プロキシノードから、セキュア近隣ディスカバリメッセージを送信するステップを更に備えることを特徴とする請求項9に記載の方法。
請求項11
前記第2のノードにおいて、前記第1のノードに関するフラッディング攻撃を検出するステップと、前記検出の結果として、フラッシュリクエストメッセージを第3のノードへ送信するステップとを更に備え、前記フラッシュリクエストメッセージは、前記第1のノードに関するすべてのバインディングキャッシュエントリをフラッシュすることを前記第3のノードに命令するものであり、前記フラッシュリクエストメッセージは、前記第1のノードに属する前記識別子と、前記識別子を生成するために使用されるその他の暗号化材料とを備えることを特徴とする請求項1乃至10のいずれか1項に記載の方法。
請求項12
通信ネットワークで使用するノードであって、第2のノードに属する暗号化属性の少なくとも一部を、前記第2のノードから受信するための受信器と、受信した前記第2のノードに属する前記暗号化属性の少なくとも一部と、当該ノードに属する暗号化属性の少なくとも一部とを使用して、当該ノードの識別子を生成するためのプロセッサとを備えることを特徴とするノード。
請求項13
前記識別子は、暗号化によって生成されたIPアドレスであることを特徴とする請求項12に記載のノード。
請求項14
前記暗号化属性は、前記第2のノードに属する公開鍵であることを特徴とする請求項12または13に記載のノード。
請求項15
前記第2のノードに属する前記暗号化属性をランダム値と連結するための手段と、連結された結果をハッシュするための手段と、結果として得られたハッシュ値の少なくとも一部を当該ノードの識別子を生成するための修飾子として使用するための手段とを備えることを特徴とする請求項12乃至14のいずれか1項に記載のノード。
請求項16
通信ネットワークで使用するプロキシノードであって前記プロキシノードに関連付けられている第1のノードに属する識別子を記憶するためのメモリと、前記識別子と、前記識別子を生成するために使用される暗号化材料を次のノードに送信するための送信機とを備え、前記識別子は、当該プロキシノードに属する暗号化属性の少なくとも一部と、前記第1のノードに属する暗号化属性の少なくとも一部とを使用して生成されているものであり、前記識別子と前記暗号化材料とは、当該プロキシノードが前記第1のノードに代わってメッセージを送信する権限を有することを検証するために、前記次のノードによって使用されるものであることを特徴とするプロキシノード。
請求項17
前記識別子は、暗号化によって生成されたIPアドレスであり、前記暗号化属性は、前記プロキシノードに属する公開鍵であることを特徴とする請求項16に記載のプロキシノード。
請求項18
前記第1のノードに関するフラッディング攻撃を検出するための手段と、前記次のノードにフラッシュリクエストメッセージを送信するための手段とを備え、前記フラッシュリクエストメッセージは、前記第1のノードに関するすべてのバインディングキャッシュエントリをフラッシュすることを前記次のノードに命令するものであり、前記フラッシュリクエストメッセージは、前記第1のノードに属する識別子と、前記識別子を生成するために使用されるその他の暗号化材料とを備えることを特徴とする請求項16または17に記載のプロキシノード。
类似技术:
公开号 | 公开日 | 专利标题
US10555162B2|2020-02-04|Home agent discovery upon changing the mobility management scheme
US8549294B2|2013-10-01|Securing home agent to mobile node communication with HA-MN key
Ng et al.2007|Network mobility route optimization solution space analysis
Arkko et al.2004|Using IPsec to protect mobile IPv6 signaling between mobile nodes and home agents
KR100679882B1|2007-02-07|사설 네트워크와 로밍 모바일 단말 사이의 통신
US7401216B2|2008-07-15|Addressing mechanisms in mobile IP
US7779136B2|2010-08-17|Secure neighbor discovery between hosts connected through a proxy
FI105965B|2000-10-31|Autentikointi tietoliikenneverkosssa
US9088938B2|2015-07-21|Information exchange between gateways for route optimization with network-based mobility management
Perkins et al.1998|Route optimization for mobile IP
KR100759727B1|2007-09-20|승인된 통신 방법
Soliman et al.2008|Hierarchical mobile IPv6 | mobility management
EP1735990B1|2018-05-30|Mobile ipv6 authentication and authorization
ES2368566T3|2011-11-18|Conexión rápida a red.
US8266427B2|2012-09-11|Secure mobile IPv6 registration
JP4750045B2|2011-08-17|ネットワーク管理方法及びネットワーク管理装置
US7793098B2|2010-09-07|Providing privacy to nodes using mobile IPv6 with route optimization
KR100450973B1|2004-10-02|무선 통신시스템에서 이동 단말기와 홈에이전트간의인증을 위한 방법
US7636569B2|2009-12-22|Method of registering home address of a mobile node with a home agent
EP1739901B1|2012-07-18|Mobile IPv6 optimised reverse tunnelling for multi-homed terminals
JP4477003B2|2010-06-09|通信システムにおける位置プライバシー
US8644256B2|2014-02-04|IP mobility
US7885274B2|2011-02-08|Route optimization between a mobile router and a correspondent node using reverse routability network prefix option
Johnson et al.2004|Mobility support in IPv6
JP2010530680A|2010-09-09|モバイルノードのためのアクセスネットワーク−コアネットワーク間信頼関係検出
同族专利:
公开号 | 公开日
CN101861742A|2010-10-13|
GB0722899D0|2008-01-02|
EP2223547A2|2010-09-01|
US20100260338A1|2010-10-14|
CN101861742B|2013-07-24|
EP2223547B1|2015-10-28|
US8295487B2|2012-10-23|
CA2706136A1|2009-05-28|
WO2009065923A3|2009-07-09|
GB2454897A|2009-05-27|
JP5250634B2|2013-07-31|
WO2009065923A2|2009-05-28|
引用文献:
公开号 | 申请日 | 公开日 | 申请人 | 专利标题
JP2004135134A|2002-10-11|2004-04-30|Tdk Corp|無線通信用アダプタ|
JP2004186989A|2002-12-03|2004-07-02|Hitachi Ltd|移動端末装置および端末間パケット通信方法|
WO2005062650A1|2003-12-19|2005-07-07|Fujitsu Limited|移動端末の移動支援装置|
WO2006119358A2|2005-05-02|2006-11-09|Ntt Docomo Inc.|Secure address proxying using multi-key cryptographically generated addresses|
JP2008541566A|2005-05-02|2008-11-20|株式会社エヌ・ティ・ティ・ドコモ|Secure address proxy using multi-key encryption generated address|
WO2007003240A1|2005-06-30|2007-01-11|Matsushita Electric Industrial Co., Ltd.|Optimized reverse tunnelling for packet switched mobile communication systems|
JP2008547339A|2005-06-30|2008-12-25|パナソニック株式会社|パケット交換移動通信システムにおける最適化されたリバーストンネリング|
WO2007043708A1|2005-10-14|2007-04-19|Matsushita Electric Industrial Co., Ltd.|Apparatus for reducing signalling data bursts in mobile network|
JP2009512236A|2005-10-14|2009-03-19|パナソニック株式会社|ネットワーク管理装置|
US20070113075A1|2005-11-10|2007-05-17|Ntt Docomo, Inc.|Secure route optimization for mobile network using multi-key crytographically generated addresses|
WO2007059419A2|2005-11-10|2007-05-24|Ntt Docomo Inc.|Secure route optimization for mobile network using multi-key cryptographically generated address|
JP2009516435A|2005-11-10|2009-04-16|株式会社エヌ・ティ・ティ・ドコモ|複数鍵暗号化生成アドレスを使ったモバイルネットワークのためのセキュアな経路最適化|JP2013511902A|2009-11-17|2013-04-04|クゥアルコム・インコーポレイテッドQualcommIncorporated|ホーム・エージェント・プロキシMIPv6ルート最適化モード|GB2367986B|2001-03-16|2002-10-09|Ericsson Telefon Ab L M|Address mechanisms in internet protocol|
GB2381423B|2001-10-26|2004-09-15|Ericsson Telefon Ab L M|Addressing mechanisms in mobile IP|
US7409544B2|2003-03-27|2008-08-05|Microsoft Corporation|Methods and systems for authenticating messages|
GB0312681D0|2003-06-03|2003-07-09|Ericsson Telefon Ab L M|IP mobility|
KR100636209B1|2004-11-12|2006-10-19|삼성전자주식회사|Mac 주소 보안 방법 및 장치|
US8098823B2|2005-05-03|2012-01-17|Ntt Docomo, Inc.|Multi-key cryptographically generated address|
US8230212B2|2006-08-29|2012-07-24|Alcatel Lucent|Method of indexing security keys for mobile internet protocol authentication|
GB2453752A|2007-10-17|2009-04-22|Ericsson Telefon Ab L M|Proxy mobile IP communications network|
US7984486B2|2007-11-28|2011-07-19|Nokia Corporation|Using GAA to derive and distribute proxy mobile node home agent keys|US9107048B2|2009-06-29|2015-08-11|Telefonaktiebolaget Lm Ericsson |Methods and systems for mobile IP route optimization|
US10044713B2|2011-08-19|2018-08-07|Interdigital Patent Holdings, Inc.|OpenID/local openID security|
CN103384233B|2012-05-02|2017-06-20|华为技术有限公司|一种代理转换的方法、装置和系统|
US9092427B2|2012-06-08|2015-07-28|Lockheed Martin Corporation|Dynamic trust session|
US8925059B2|2012-06-08|2014-12-30|Lockheed Martin Corporation|Dynamic trust connection|
WO2015096906A1|2013-12-23|2015-07-02|Nec Europe Ltd.|Method and system for assessing a message in a decentralized communication network|
US10652012B2|2018-02-21|2020-05-12|Verizon Patent And Licensing Inc.|Global identification of devices based on designated IPv6 address|
法律状态:
2011-10-22| A621| Written request for application examination|Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20111021 |
2012-11-29| A977| Report on retrieval|Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20121129 |
2012-12-11| A131| Notification of reasons for refusal|Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20121210 |
2013-01-29| A521| Written amendment|Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130128 |
2013-03-15| TRDD| Decision of grant or rejection written|
2013-03-25| A01| Written decision to grant a patent or to grant a registration (utility model)|Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20130322 |
2013-04-18| A61| First payment of annual fees (during grant procedure)|Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130415 |
2013-04-19| R150| Certificate of patent or registration of utility model|Ref document number: 5250634 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
2013-04-22| FPAY| Renewal fee payment (event date is renewal date of database)|Free format text: PAYMENT UNTIL: 20160419 Year of fee payment: 3 |
2016-04-12| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2017-04-18| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2018-04-17| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2019-04-16| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2020-04-09| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
优先权:
申请号 | 申请日 | 专利标题
[返回顶部]